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Abstract 


Internet mail defines the From: header field to indicate the author of the message's content and 
the Sender: field to indicate who initially handled the message on the author's behalf. The 
Sender: field is optional if it has the same information as the From: field. This was not a problem 
until development of stringent protections on use of the From: field. It has prompted Mediators, 
such as mailing lists, to modify the From: field to circumvent mail rejection caused by those 
protections. In effect, the From: field has become dominated by its role as a handling identifier. 


The current specification augments the altered use of the From: field by specifying the Author: 
field, which ensures identification of the original author of the message and is not subject to 
modification by Mediators. This document is published as an Experimental RFC to assess 
community interest, functional efficacy, and technical adequacy. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for examination, 
experimental implementation, and evaluation. 


This document defines an Experimental Protocol for the Internet community. This is a 
contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has 
chosen to publish this document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by the RFC Editor are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9057. 


Copyright Notice 


Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights 
reserved. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
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1. Introduction 


Internet mail conducts asynchronous communication from an author to one or more recipients 
and is used for ongoing dialog amongst them. Email has a long history of serving a wide range of 
human uses and styles, within that simple framework, and the mechanisms for making email 
robust and safe serve that sole purpose. 


Internet mail defines the content header's From: field to indicate the author of the message and 
the Sender: field to indicate who initially handled the message on the author's behalf [Mail-Fmt]. 
The Sender: field is optional if it has the same information as the From: field. That is, when the 
Sender: field is absent, the From: field has conflated semantics as both a handling identifier and a 
content creator identifier. These fields were initially defined in [RFC733], and making the 
redundant Sender: field optional was a small, obvious optimization in the days of slower 
communications, expensive storage, and less powerful computers. 


The dual semantics were not a problem until development of stringent protections on use of the 
From: field. It has prompted Mediators, such as mailing lists, to modify the From: field to 
circumvent receiver mail rejection caused by those protections. This affects end-to-end usability 
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of email between the author and the final recipients, because mail received from the same 
author is treated differently by the recipient's software, depending on what path the message 
followed. 


By way of example, mail originating with: 


From: Example User <user@example.com> 


which is sent directly to a recipient, will show the author's display name correctly and can 
correctly analyze, filter, and aggregate mail from the author based on their email address. 
However, if the author sends through a mailing list and the mailing list conducts a common form 
of From: modification needed to bypass enforcement of stringent authentication policies, then 
the received message might instead have a From: field showing: 


From: Example User via Example List <listname@list.example.org> 


The change inserts an operational address, for the Mediator, into the From: field and distorts the 
field's display name as a means of recording the modification. 


In terms of email identification semantics, this is a profound change: 


e The result is that the recipient's software will see the message as being from an entirely 
different author and will handle it separately, such as for sorting or filtering. In effect, the 
recipient's software will see the same person's email as being from a different address; this 
includes the person's actual address and each of the mailing lists that person's mail transits. 


e Mediators might create a Reply-To: field with the original From: field email address. This 
facilitates getting replies back to the original author, but it does nothing to aid other 
processing or presentation done by the recipient's Mail User Agent (MUA) based on what it 
believes is the author's address or original display name. This Reply-To action represents 
another knock-on effect (e.g., collateral damage) by distorting the meaning of that header 
field, as well as creating an issue if the field already exists. 


In effect, the From: field has become dominated by its role as a handling identifier. The current 
specification augments this altered use of the From: field by specifying the Author: field, which 
identifies the original author of the message and is not subject to modification by Mediators. 


While it might be cleanest to move towards more reliable use of the Sender: field and then to 
target it as the focus of authentication concerns, enhancement of existing standards works best 
with incremental additions, rather than with efforts at replacement. To that end, this 
specification provides a means of supplying author information that is not subject to 
modification by processes seeking to enforce stringent authentication. 


This version is published as an Experimental RFC to assess community interest, functional 
efficacy, and technical adequacy. See Section 7. 
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2. Terminology 


Terminology and architectural details in this document are incorporated from [Mail-Arch]. 
Normative language, per [RFC8174]: 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


3. Author Header Field 


Author: is anew message header field being defined. It has the same syntax as the From: header 
field [Mail-Fmt]. As with the original and primary intent for the From: field, the Author: field is 
intended to contain the email address of the author of the message content. It also can contain 
the displayable human name of the author. 


The [ABNF] for the field's syntax is: 
author = "Author:" mailbox-list CRLF 


which echos the syntax for the From: header field. 


This header field can be added as part of the original message creation process, or it can be 
added later, by a Mediator, to preserve the original author information from the From: field. 


The goal of the Author: field is to reflect information about the original author. However, it is 
possible that the author's MUA or Mail Submission Agent (MSA) will not create it but that a 
Mediator might know it will be modifying the From: field and wish to preserve the author 
information. Hence, it needs to be allowed to create the Author: field for this if the field does not 
already exist. 


Processing of the Author: field follows these rules: 


e If an Author: field already exists, anew one MUST NOT be created, and the existing one MUST 
NOT be modified. 


e An author's MUA or MSA MAY create an Author: field, and its value MUST be identical to the 
value in the From: field. 


e A Mediator MAY create an Author: field if one does not already exist, and this new field's 
value MUST be identical to the value of the From: field at the time the Mediator received the 
message (and before the Mediator causes any changes to the From: field). 
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4. Discussion 


The Author: header field, here, is intended for creation during message generation or during 
mediation. It is intended for use by recipient MUAs, as they typically use the From: field. In that 
regard, it would be reasonable for an MUA that would normally organize, filter, or display 
information based on the From: field to give the Author: header field preference. 


Original-From: is a similar header field referenced in [RFC5703]. It is registered with IANA, 
which cites [RFC5703] as the controlling source for the entry. However, that document only has a 
minimal definition for the field. Also, the field is solely intended for use by Mediators to preserve 
information from a modified From: field. The current specification can be used during either 
origination or mediation. 


While the basic model of email header fields is highly extensible, there well might be 
implementation and usability considerations for carrying this field through to end users, such as 
via [IMAP]. 


Obviously, any security-related processing of a message needs to distinguish the From: field from 
the Author: field and treat their information accordingly. 


5. Security Considerations 


Any header field containing identification information is a source of security and privacy 
concerns, especially when the information pertains to content authorship. Generally, the 
handling of the Author: header field needs to receive scrutiny and care, comparable to that given 
to the From: header field, but preferably not in a way that defeats its utility. 


Given the semantics of the Author: header field, it is easy to believe that use of this field will 
create a new attack vector for tricking end users. However (and perhaps surprisingly), for all of 
the real and serious demonstrations of users being tricked by deceptive or false content in a 
message, there is no evidence that problematic content in a header field, which is providing 
information about message's author, directly contributes to differential and problematic 
behavior by the end user. (The presents an obvious exercise for the reader to find credible, 
documented evidence.) 


6. IANA Considerations 


IANA has registered the Author: header field, per [RFC3864], in the "Provisional Message Header 
Field Names" registry: 


Header field name: Author 

Applicable protocol: mail 

Status: Provisional 

Author/Change controller: Dave Crocker <dcrocker@bbiw.net> 
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7. Experimental Goals 


Given that the semantics of this field echo the long-standing From: header field, the basic 
mechanics of the field's creation and use are well understood. Points of concern, therefore, are 
with possible interactions with the existing From: field, anti-abuse systems, and MUA behavior, 
along with basic market acceptance. So the questions to answer while the header field has 
experimental status are: 


e Is there demonstrated interest by MUA developers? 
e If MUA developers add this capability, is it used by authors? 


e Does the presence of the Author: field, in combination with the From: field, create any 
operational problems, especially for recipients? 


e Does the presence of the Author: field demonstrate additional security issues? 


e Does the presence of the Author: field engender problematic behavior by anti-abuse 
software, such as defeating its utility? 
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